TV services broadcast over an IP network are referred to as IPTV. IPTV is typically broadcast using a broadband access network, and the predominant IPTV service is Broadcast TV, in which the normal non-IPTV channels, as well as additional channels with low penetration are transmitted over the broadband network from a super head-end down to an end-user's set top box (STB).
Linear content delivery, in which all channels in a subscription are simultaneously delivered to a user's set top box (STB) is not suitable for IPTV, as IPTV has limited bandwidth available over a broadband connection. A typical ADSL broadband connection provides a capacity of between 3 and 8 Mbps, and ADSL2 promises to deliver up to 25 Mbps downstream, whereas VDSL can provide a capacity of greater than 30 Mbps. Standard quality MPEG 2 IPTV content requires 2 Mbps per channel, and HDTV will require around 8-10 Mbps per channel The MPEG 4 standard will approximately halve the bandwidth required to deliver IPTV content with the same quality. Nevertheless, the available bandwidth is a scarce resource, and IPTV solutions must limit the number of channels that can be delivered simultaneously.
In order to minimize the bandwidth required for transmission of IPTV content, it is necessary to use multicast techniques through the network. When the end-user switches from one channel to another, the STB sends out an Internet Group Management Protocol (IGMP) Leave message for the channel that the STB is currently receiving, and an IGMP Join message for the new channel that the user wishes to receive.
The IPTV content contains MPEG (normally 2 or 4 part 10) frames. There are different frames in MPEG, such as I-frames, P-frames and B-frames. I-frames do not depend on data contained in the preceding or following frames, as they contain a complete picture. P-frames provide more compression than I-frames because they utilize data contained in the previous I-frame or P-frame. When generating a P-frame, the preceding frame is reconstructed and altered according to incremental extrapolation information. B-frame are similar to P-frames, except that B-frames interpolate data contained in the following frame as well as the preceding frame. As a result, B-frames usually provide more compression than P-frames. Typically, every 15th frame or so is an I-frame. P-frames and B-frames might follow an I-frame as follows: IBBPBBPBBPBB(I). The order and number of framews in the sequence can be varied.
Since B and P frames depend on adjacent frames it is necessary that when the STB receives a new channel, it receives a full I-frame before the new channel can be shown. The average time for switching between channels therefore depends on the length of time between I-frames. Typically, for MPEG-2 IPTV content, the length of time is around 0.5 seconds. For MPEG-4 part 10 IPTV content, the length of time between I-frames can be several seconds.
Other sources of delay include:                The buffer in the STB        The time it takes for the IGMP Leave/Join actions to be sent and actioned.        
There is therefore a problem in that when an IPTV user changes channel, there can be a significant delay between the STB no longer receiving IPTV content the old channel, and the STB receiving and rendering the IPTV content of the new channel, which is detrimental to the user experience.
Some solutions have been proposed to alleviate the problem associated with the delay in channel switching. For example, an Omicron solution describes fast channel switching between MPEG-streams, although this was not designed for IPTV.
Another solution is to use a Reliable Transmission Protocol (RTP) switch. This switch resides in the network from which the IPTV is broadcast, and buffers RTP streams containing MPEG frames. When the RTP switch receives an IGMP Join message it immediately sends the I-frames from its buffer to the STB.
A further solution is to begin a unicast session when the user changes channel, in order to send the frames to the user as quickly as possible. Once synchronisation of the frames from the unicast with the multicast is possible, then the user switches to receiving the multicast session rather than the unicast session.
A problem with the RTP-switch solution that most channels are encrypted. The RTP-switch therefore has difficulty “seeing” what kind of frames it receives, that is to say whether frames are of I, P or B type. Decrypting and re-encrypting is of course one possible solution, but this would necessitate an expensive increase in processing power required. This is also a problem with the unicast solution described above.
The unicast solution has additional drawbacks. Firstly it requires that the available bandwidth on the “last mile” (for example, the DSL-line connecting the user to the network) is sufficiently high to allow the user to download both unicast and multicast data concurrently, at least for a short time after changing channel In addition, the unicast solution has a scalability problem. For example, when a very popular programme ends, a large number of people who have been watching the programme will then start to zap (the term “zapping” is used herein to mean changing channels using the up and down or the number buttons on a STB remote control) simultaneously. It is not feasible to start unicast session to all those users unless the number of servers is very large. Yet another drawback is that the STB needs to implement the functionality of downloading the unicast and the multicast simultaneously, which can be quite complex.
There is a need for fast channel switching that does not require the STB to simultaneously download a multicast and a unicast, and can also be used for encrypted video multicast streams.